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(54) Title: SYSTEM AND METHOD FOR PRESENTATION OF COMPUTERIZED PATIENT RECORDS ACROSS A NETTWORK 

(57) Abstract 

This invention includes systems 
and methods for the networked distri- 
bution and personalized presentation of 
computerized patient record ("CPR**) in- 
fomiation. In particular, the invention 
includes networked computer systems 
structured into third-tier systems, on 
which reside data server-objects, sec- 
ond tier systems, on which reside busi- 
ness-server objects, and first-tier sys- 
tems, on which reside object-oriented 
user interface applications. The busi- 
ness-server objects read data from the 
data-objects, personalize and forniat the 
data, and present it to the user inter- 
face application. Data personalization 
and formatting follows recommenda- 
tions remmed from rules modules pro- 
cessed by a rules engine using data from 
a personalization database. The rules 
modules advantageously centralize the 
rules, instead of leaving the rules dis- 
tributed and embedded throughout the 
application logic. Additionally, deci- 
sion support services can be integrated 
into the system by the addition of neces- 
sary mles modules to the system knowl- 
edge base. 
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System and method for presentation of computerized patient records across a network. 



1. Field of the Invention 

This invention relates to networked computer systems, in particular to 
networked computer systems with object-oriented software for the personalized presentation 
and formatting of computerized patient records. 

2. Description of Related Art 

Medical institutions generate voluminous records of a wide variety of types in 
the course of patient treatment. Computer storage and distribution of these records are 
needed to address the well-known problems with paper records and image in integrated 
medical case delivery systems. Computerized patient records ("CPR") are inherently 
multimedia, ranging as they do from alphanxmieric data, such as free text and structured 
reports, to non-alphanumeric data of many types, such as medical images, video streamfr^ * "" 
monitoring signals, voice dictation, and other graphics. For example, CPR information for a 
given patient includes demographics, admission, dLischar^ laboratoiy 
results, radiology reports, images,, ordered niedications, operative and procedure notes, 
progress notes, the status of orders and. procedures, and so forth.: .^.^ ; . , j - 

. Access to distributed data has been hugely expanded by the great success of.: 
the intemetworking suite of communication protocols, which have succeeded in linking 
together diverse networks of devices rmging from persdnal digi " 
supercomputers. Data residgsnt bri all these devices has suddenly'ibecome remotely accessible 
from virtually anywhere. Further^ World Wide Web protocols rurming on the public hitemet 
have created imprecedented capabilities for imiform access to and* standardize distribution of; 
these vast stores of computerizei^ data. . - ; . • - 

' Fiirther, creation amd operation of distributed processing applications h^ 
been simplified by distributed object-oriented technologies. "Object-oriented programming' 
methodologies are known to have improved and streamlined the application development - 
process. Distributed object-oriented technologies now are welding together diverse object- ' 
oriented application across networks, including TCPAP -based networks such as the Internet, 
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by creating a softv^are bus ?tructure, fpr uniform exchange of processing requests. Exemplary 
of such distributed object-oriented technologies are the standards j>romulgateil ^y3the Object 
Management Group (Newton, MA) ("OMG"). •* c / - 

Application prpgramnung. (programs written to solve specific business 
5 problems) has also been enabled by the use of rule-based techniques. An examplciof such 
techniques is the representation of an organization policies and practices by business rules. 
However, writing, interpreting and maintaining business rules has often been difiFicult for the 
business analysts that are responsible for specifying business rules. For example, business 
rules have been historically embedded directly in the prpcedural flow of application 
1 0 programs. This approach has the disadvantage that itis- very difficult to change the rules to 
cope with chancing business conditions. Business rules have also been implemented in 
database procedures known as database triggers. Database triggers and stored procedures are 
modular and isolate the business rules from the application logic. However, they require 
, , SQL prpgramiriing. It is often difficult to interpret the business logic by looking at the SQL 
1 5 code. Database triggers are also hard Xo maintain and. change for adapting to changing i 
business policies,,; - 

" Finally , efficient and effective. integrated storage, management, distribution, 
: iarid'pfeseijtati^^^ forms of medical data in a flexible and evolving manner is 

, goal that has eluded current nie4ical in^^ ; What is needed are methods and 

20 systerns^ that address the problems of cpmputerized medical records by-rnaking effective use v 
- ^ of the n^w hardware ^^ ,§9ft^?r?-^?C;})pologies spch as those mentioned above. . : , 

Citation or discussion of a reference herein, or throughout this specification, is 
not an^admi^sipn tliat such reference is prior, to the inventipii of the: subject matter 
subsequently claimed.,. f-.;... . . , ^ . / . 

25.-,'.. /; -'l^r^-J^'.^-L, ■.: ~ ■.. 

Accordingly, an object of this invention is methods and systems for efficient 
arid effective integrated storage, naanagenient,, distribution, and .presentation of all the various 
forms of medical data, in a flexible and .evolving manner by coordinated.and.novel. use of the 
30 . Jephnolqgies .of networked computer systems, distributed object-oriented technologies, and - 
rules-based processing foikdata distribution, personalization, and presentation:; The methods 
and systems of this invention, are not limited tO; medical institutions, but can also be . i 
^advantageously employed outside of tiie medical' arena. 
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• . , . Method arid systems are desdribed for personalization anci formatting tile 
presentationof CPR data' depending on a"iiser's role in a medical institution and a user's end- 
user devices, from personal digital assistants to powerful workstations. ' Personalized 
visualization of CPR information provides users with relevant information that is targeted for 
them and their end-user devices. For example, clinical users can use the present invention to 
access lii©dicatrecords quickly froni a variety of networked end-user devices across the 
medical enterprise as well as at home and traveling. 

The personalization and formatting of CPR data is performed in accordance 
with recommendations returned from a plurality of business rules which taike into account the 
policies and practices or an institution as well as system and device capabilities. According 
to this invention, these rules and bflief policy and* business logic are centralized in the rules 
engine and rules modures. This'is different^fr-bm the conventional approach of embedding 
business rules as code in application programs. - ^ : 

^ Centralizing business rulesiri a rules engine'has benefit^' Including allovmig 

the medical institution to react quickly to operating and regulatory conditions. Separating ' 
business logic from application logic allows organizations to change business policies 
without rewriting or-recomipilihg applibation codeV^ This ardhitectiire is particularly suitable 
for distributed en virolomients because it eliminates- the need to tipgrade clfefat software fevery : 
time tiiere is a change in business policy. TWs afchite"btOTe'can also'bbttei: sfUjjijdrt changing 
rules because^fersonializatibn-and decision support logic' re'sides outsidd df tke application 
logic. Other distributed application using "complex busineiss logic are also well suited for the 
methods of this invention. ' - - : > , . c; :r • .v.- 

\ . ' M k'*pr€feited embodiment^- this invention- utilizes a ifetworked computer 
system ftmctionally differentiated into a three-tiered architecture an3 linked by distributed 
object-oriented technology, such as the Common Object Request Broker ("CORBA") of the ' 
OMG. The invention includes rules-based business-server objects, a plurality of rules 
.modules,iand a :rules- engine. ' ^ ' ^ ^ ^ * ; . . ' * 

' ^ t'^ T3ie niles-blsed'busiriess-sei^^er^^ 
results j load^elevant rules and pass 'thena to the rules engirie,^and process the user requests by 
. following the recommendations retiimfed" from the niles engine. Different rute-based server ' 
objects'are implemented for different rule-modules to improve scalability and mdritenance. 
The rule-based business-server objects have static or dynamic CORBA initerfaces. 

The rules are generally divided into personalization and decision Support rule 
families which are centrally stored as rule modules accessed only by the business-server 
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objects and the rules engine server. Use of many modules improves performance and avoid 
undesirable interaction between certain rules. The personalization rule modules preferably 
include an orders and forms rule module, a printing rule module, . a . help rule module, and a 
GUI layout rule module. The decision. support rule modules preferably include an alerts and 
reminders rule module, a drug-drug interaction rule module, and a diagnosis, and 
interpretation rule module. 

The rules engine is adapted to process the rules and return processing 
recommendations tp the business-perver objects. In a preferred embodiment, the system is 
coded in Java"". The end-user devices interface to the user by Java*", applets inside a browser 
or as a standalone application. 

In a first embodiment, the present invention includes an .object-oriented system 
for computerized patient record (CPR) presentation to a user at an end-user device the 
object-oriented system for impl^ementation on computers connected by a network, the system 
comprising: one or more medical-records-seryer objects comprising CPR-request methods 
that input requests for Cf»R data, access requested data in CPR databases, and return 
requested CPR data, a presentation application resident in the end-user device that accepts 
user requests, inyokfs methods of business-server objects with parameters representing user 
requests, and displays.responses returned by' the business-server objectjnethods, one or more 
business-server objects comprising the business-server object methods invoked by said 
presentation application, wherein the business-server object methods process input 
parameters to determine if CPR data is to be pbtjdned,. and if so which CPR data, authorize 
access to the determined CPR data, invoke the CPR-request methods, of said medicalrrecords- 
server objects to obtain authorized CPR data, format a.response including any returned CPR 
data, and return the respoMe |o. said presentation eippiication,-and wherein the authorizmg 
and formatting are responsive to a plurality of rules retrieved from a rule database and to - - 
personalization data retrieved from a personalization database, the rules comprising (i) 
access-control rules for authorizing access to CPR information and (ii) presentation-control 
rules for guiding formatting of responses. .. - 

. . 5 .s?9ond embocjiment the present invention includes a method of presenting 
computerized patient records (CPR) on an end-user device by an object-oriented system 
implemented on computers connected by a network, the method comprising: accepting a user 
request and invoking one or more methods of business:S.erYe.r objects, wherein parameters 
input to the business-server object methods represent the user request,- and wherein said 
accepting and invoking are performed by a presentation, application in the end-user device. 
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-* • ' determining if CPR datk is to be obtained for the user, and if so which CPR data, wherein 
said det'erThining is perfdnned by the busiiiess-server objects according to the input 
' parameters, authorizing the determined CPR data according to authorization 

recommendations returned from processing both of access-control rules retrieved from a 
5 rules database and also of personalization data retrieved from a personalization database, 
w^herein said authorizing is performed by the business-server objects, invoking one or more 
methods of medical-records-server objects, wherein parameters input to the medical-records- 
server objects represent the authorized CPR data, wherein the medical-records-server objects 
* return the authorized CPR data retrieved from CPR databases, and wherein said invoking is 

10 performed by the business-server objects, formatting and retuming a response to the 
presentation appilcation, w^herein the response includes returned CPR data, wherein the 
formatting is according to fofiriatting recommendations returned from processing of. 
presentation-control rules retrieved from the rules database and personalization data retrieved 
from the personalization database, and wherein'the formatting' and retuming is performed by 

1 5 the business-server bbjects, arid displaying the rehorne'd response to the user by the 

presentation application. ^ ^ ■ ^ ' . 

-■- ' . 

"Other embodinients and aspects are defined in the further ipde^^ 

dependent claims. ' * - v:^ . > 



20 



30 



' ' ^' ' Other objects, features and aldvantages of the present invention will become 
appajrent upon pehiisal of the following detailed descripti^^ 
the appended drawing, whereiii: 
- ^' ' ' * " Figs. 1 A-B illustrate exemplary .sykem ih^&astnlct^ utilized by tiie present 
25 ' iiivention; - . * 

* ^ Fig. 2 illustrktes a preferred' distributed bbje 

rules binding; * 

Fig. 3 illustrates structure according of the present invention; and 
' ' Fig. 4 illustrates the* general processing seqUef^^ 



The methods aiiid systeifi^ of this ihven'tioh' achieve the networked distribution 
and personalized presentatioii of compiiterized patient record ("CPR") data on a wide variety 
of first-tier, end-user devices from a variety of third-tier back-end data-storage systems by 
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using second-tier object-oriented sep'er. systems. The distributed, .networked systems and 
object-oriented software infrastructures of the present invention are described first in- the 
following. Described second are the rulerbased. server objects which reside on the second- 
tier server systems and carry put-the distribution and .personalized presentation on end-user 
5 devices. _ . . ^ • .- . . » 

Herein, CPR data is taken to include the entire gamut of medical information 
collected for patients at one or more medical institutions or providers and capable of 
computer storage, For ex^ple, QPR,data for a patieiit can include past and present 
information, perhaps spanning, the patient's entire life, of the following types: patient 
1 0 demographics; admissions, disc^iarges and transfers; medical progress notes and discharge 
summaries; notes of operatiy^.and oAer procedures; radiology reports; laboratory results; 
medications; x-ray, magnetic.reson^ce, .ulfrasound, and other images; the status of ordered 
procedures and medications; and so forth. 
General Distributed Systems- Infrastructure , 

Fig- 1 A illustrates an exemplary embodiment of the distributed system 
infr^tructure utilized,by the present invention. This figure illustrates only the general classes 
of computers, devices,: cop:punicatipn links, and networks utilized in the present invention; 
the'paj^c^^ . •■ 

.. . . ! .^^/^^^^^^ 1 A iUusti^tes, the system infrastnicture.ineludes.net^^ 

bi-W^^^ computers fiijictioniiigpiim^^^ not necessarily exclusively) either; as .third- . 
tier back-end computer, s.qppndrtier, ^eryer^^ first-tier end-user computers or 

.devices. ^ Back-end. computers, s^ch 10 . and 11, are adapted for permanent 

.V .= : : i ^°I^^f °^ -Tfe^;. ^?:^.'^y^^g?°^^y provided with adequate with processing 

resources, ^ain ,n^e,mpiy,.aiid^ storage;12 which may be 

25 magnetic or.optical, and. with database, and application software, either legacy, software or ; 
software initially 4esigned as object-oriented, for, managing^ attached, storage facilities and 
presenting its contents. . ,. ...-„ . .j . . .. - . ^ 

• ^^'^PJ:r^°"^P"^^rs, suphaseomputei;s.l3an.d.l4, are a 
phased server pbjects of tlie .present inven^ which are .invoked by req^ests from end-user 
30 devices ^d which. in turn invojce^datarsen'er.ob^^^^ 

Adyantagppusly, server computer are p/Qvided withprocessm and:stprage 
resources adequate to demands of the rule-based server objects and of the.distributed object- 
oriented infrastructure also resident on these computers. 
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- The computers and end^xiser devices bf this invention are networked using 
physical-linlcs-dTvmoixs types/ Fijg/IA illustrates hetWork 15 providing for general 

- conhectivit}', such as the public Internet or one or'fnofe private intranets implementing the 

' - - Interiiet suite of eonunuiii cation protocols including TCP/IP: Terminal links 16 to computers 
5 10, 1 1, 13, and 14 can be high-speed telephone lines suitable for data server traffic. 

Computers can also be directly connected by local arek networks ("LAN"), such as LAN 1 7, 
Finally, Fig. lA al^b illustrates exemplary end-user devices 28 including: personal computers 
("PC") 17%nd 18, which have now standard architecture^ aiid operating systems: television 
set 22 with Intemet^nterface device 22'; Eind highly portable ehd-usef devices such as display 
1 0 pager 21 , cell-phone 20 v^th display capabilityX"screen-phone"),'and personal digital 
assistant 19 ("PDA"). Terminal networic \w& td these' eftd-user devices can have'widely 
varying characteristics arid bandwidth. For "exam'ple, terminal PC links 27 can be switched 
telephone lines; terminal TV link can be a residenti^ CableVterininal pager and cell-phone 
links 24 and 25 will certainly be wireless, while temHiiaW^DA liiflc26 can be alternately" 
15 wireless or wired. - - ^ ' " ^ *" ' 

^ - - ' Generally the present invention is compatible with eri 

can request and display World Wide- Web ("WWW'*) coiiteh^l'for example documents 
formatted in Hypertext Markup' Language ("HTML")iind' distributed accoMing t 
Transfer Protocol ("HTT^"), and also-iisrve sulfficieiit resideht software to be able to interact 
20 ( with the distributed, object-oriented infrastructiire o? tiie presetit invention. As illustrated, a 
: br6ad range of such devices having specialized fbnctiorialhy ahd portability are now 

- available. Further such devices contiiiue to be deveiopedV A!fter study of the subsequent 
description, it will be'appfarerit taone of 'skiU in the krt that stfch devices caii be utilized in the 
preseftt invention in a routine tnahner simply by proViiiiiig tiie devrce v^th a browser jprogram 

25 -capable^of nHiiiihgJaVi— applets' and a Java^*^^^ - " 

: • . * ^ ■ Ai will be apparent to one ot sBH ih^the art from' the ^ubseqiient disclosure that, 

although the computers and devices preferably function in this invenii'ori primarily in one of 
' ) the three roles disclcfsed above- bec^iise oF Relocation transparency present in the software 
infrastructure; software^ ftinctions and fuhctioriaF f oieis of computers can be allocated freely. 
30 For example, although not presently- pfefefable,^it is possible for all the components of this 
invention to reside one eofnpiiter with network attached end-usei' cdtnputers and devices, or 
even-on a~sihgle computer.- ' • " ^ " - • * 

Computers, including PC*s, having standard architectures are suitable for use 
in the present invention. Fig. IB illustrates exemplary computer 36 with one or more 
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,P^^^^.^^?^ ™^ 1, Storage interfaces 32 with pennanent storage devices 33 

utilizing magnetic and optical technologies, external interfaces 34 to user displays and 
communication links, and buses or switches 35 interconnecting these components. . 
Computers and operating and database softv/are are widely available from, e.g.. Sun. 
5 Microsystems, Compaq, IBM, Microsoft, Redhat Software, and Oracle. 

End-user devices of specialized fimctionalities have evolving structures and 
operating software. Exemplary devices are available from, e,g, , Philips Electronics, Nokia, 
3Com, and Psion, with software from, e.g., Microsoft (Windows CE), the Symbian joint 
venture, and Sun Microsystems (Java'™ Development Kit). 
10^ General Distributed Object-oriented Software Infrastructure 

The present invention includes software objects of ftinctions to be described, 
which utilize a distributed object-oriented infrastructure for communication between 
networked computers. Objects and object-oriented infrastructures are known to those of skill 
in the art. See, e.^^^Vogel et al., 1998, Java^ Progranmiing with CORBA . John Wiley & 
1 5 Sons, Inc., New York; Object Management Group, Inc, ("OMG") (Newton, MA; and 
http;//www.omg.org). 

Generally, software objects are encapsulated collections of procedures, 
referred tcf as meti^^^ on by th? methods. Encapsulation means that, 

preferably, an object's extemal interface is limited only to invocations. of its public methods. 
... Accordingly, each object's data remains. preferably hidden to programs other than the object's 
methods. 

r ' - , ' , Figi .IB illustrates, ofcomputer 
_ 36, Objects 37 consist of collecti^ object data 39 and object methods 3,8, here denoted 
by opl(.), op2(.X and pp30), Preferably, the only extemal. interface presented by objects 37 
25 consists of the methods oplQ, op2(.), and 053(0, and only by.invqkiiig these.methods can : 
ai^other program gain even indirect acc«^ - , ,j 

. Objects are usually designed to mpdd 
^escribes and models aspects of ,the state^of the^.correspon^ing.realr.world entiti and object 
m.ethods model actions on the corresponding re^- world .entities by causing changes-of state 
30 ^ and producing outputs, in response iq input parameters that are similar to real-world actions 
on the real-w,orld entities. . hi other words, invoking a method.produces changes object data 
and prpduces results in a manner corresponding to a real-world action performed: on a real- 
. worldentity. . . _ . . , ^ . . 
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* * Accordingly, ah object resident in a computer's memory causes the computer 
■^to simixl^te the real- world entity modeled by "the object. Processing of a system structured as 
a plurality of client objects resident in computer memories which invoke methods of a 
plurality of server objects, also resident in the computer memories, c5ause the computers to 
5 successively simulate the client and server real-world entities modeled by the client and 
server objects, respectively. 

" Client, server, and other interacting objects need not only be co-resident on 
one computer, but can also be resident in the memories of a plurality of networked 
computers. In this case, the routing remote method invocations between client and server 
10 objects is managed by software components xeferred to as object request brokers ("ORB"). 
An ORB resident in the niemoiy of each networked computer achieves location transparency 
and portability by activating necessary instances of server objects, transparently managing 
the communication details of remote method invocations, and optionally providing other 
services such as object persistence and object replication. Accordingly, the ORBS for an 
1 5 object-oriented software infrastrufcture which insulates a client object from any concern either 
with the identity of its computer or with the identities of computeffs with server objects. 

The' objects of this invention are preferably programmed in any programming 
language providing object oriented featiires. The C-H- langiiage is preferred; the Java*^ " 
language is even more preferred. 
'*20 ' - Various commerciaLlly available dislribu^^^^ 

be used in this invention. The preferred distributed infrastructures conform to the CORBA 
• * • family of standards developed by the Object Management ^6rbup,Thd. ("OMG"). CORBA- 
- • ' ^ coriipliant infrastructifres are widely available, and include products of, infer alia, Inprise, 
' - Inc: (hftp://www.-inprise.com), lONA Techilologie^^ 

25- http://Www.i6na;comj, and ORL (http://www.cam-6rl.co,uk ). 'The Java^ language 

development kit availableirbm'SUn Microsystem's also includes a^Java"" ORB. Although the 
subsequent description of the^preiferi-ed embbdimerit is directed to CORB A-compliant 
** . distributed object-oriented iiifragtructiire^, this invention is not so limited' and can be built on 

" other infrastructures of coniparabl^ For example, this invention can also be 

30' built with'the Compoiient Object Moddl and ActiveX fechnologie Microsoft Corp. 

' " With reference to Fig; 2, certain details bf tiie preferred CORBA-compliant, 
distributed, bbject-'oriented' infrastructure arc described next. Included in a CORBA- 
compliant infrastructure is an Interface Definition Language ("IDL") implementation. IDL is 
a standardized, purely declarative language which program language bindings for defining 
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object interfaces in a object-orientieci system.. Compiling IDL. object definitions generates 
client IDL stubs 103 and s.erv^r E).L skeletons 105. ,The clientJDL stubs, called-by client 
object 109, include code to marshal a method call and its parameters into.a linear form for 
network transmission to, the server object by the conimunication ORBS. The server skeletons 
5 include code so that server objects U 0 can receive the marshaled method call andxonvert 
them into the static interfaces of the server objects. 

CORBA provides two types of object interfaces. The static interface, which is 
inore efficient but less flexible, is used if the invoked server-object methods are available as 
. .IDL definitions at compile time. The dynamic interface, which is less efficient but more 
1 0 flexible, allpws a server objects methods to be discovered. at run tune. Client object 109 
invokes dynamic invocation interface 1 02 to discover hovv^ to invoke dynamically boxmd 
methods through dynamic skeleton, invocation interface -106. - • 

Object Request Broker (ORB) 100, besides being accessed through the static 
and dynamic interface, also has application programmmg-interfaces ("API") to its own local 
1 5 services. ORB core, provides basic location transparency.. CORBA ORBs resident on 

networked computers communicate using the generalized inter-orb protocol (" GIOP") over, 
- for ex^ple, communication link 1 13,. for routmg method invocations. TheJntemet Inter-orb 
• - ::^PrdtocdI;:("^^^ GipP^ Miplementation using the TCP/IP communications 

protocol suite forvcommunication across the Internet or private intranets, 
20, ^ : , , The ORB includes^.compo»nent.interfa 101, implementation 

. . ; . , repository 102,. ?!nd. object- adap^^ The.interface repository provides services for 

, ^ dynamic^ly ^^oring and updating object-description ("metadata") information. 

- - , Th^ impleipentatipn.reppsitpry is a run-time repository of information about server object 
_ classes, instantiated (in.other. words,, activated) objects and object.references, and object 
25 lpcation.invthe,nf twQrk. The object adapter records in the implementation repository objept 
, references pf iiistaiitiated server objects.,^ The ORB uses the implementation repository to 

. actiy ate server objects and to locate^^^ The object adapter provides 

. ^ . additipnal services, to server objects, such as support for instantiating (or, activating) server 
: :; : P^^^?? method invocations, _and assigning them network adckesses known as 

30 object references.. . . ...... . ^. 

. r . * A . CORB A. implenientatioii may include stands 

CORBA Common Services and Conimon Facilities standards.- One such service is ja 
standardized user authentication.and security service. 
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'Rule's modules 111* and rules engine 1 1 2' are not part of the COKB A standard, 
^ aiki are described subsequently as part of the present ihvehtio^^ 
' System- Smict'ure of the Present Invention 

Fig. 3 inustrates'the preferred allocation of the software fUhctions and objects 
5 of the present invention v^thin the distributed object-oriented infrastructure linking the 
networked system computers. The preferred allocation lUustreLted is referred to herein as 
"thr^ tier", since it includes a third tier of back-end computers, a second or middle tier of 
server computers, and a first tier of end-user devices or computers. Each tier is described 
next, fc^lowed by more' detailed descriptions of the business-sferver objects, preferably 
10 ' allocated to server cdhiputers* and associated software functions and data. 
- Xs^prfeviou^y describfed^ alternate object and function allocation^ are routinely 

possible because of the localtibn transparency provided by the distributed, object-oriented 
infrastructure. - . ^ - i - 

The First Tier - EfKd-user Devices f'?);;rL.. . ^ . 

15 • ' The first tier includes interactive, end-iiker dfe vices'. Illustrated in Fig. 3 are 

' - specialized end-user device 50; which can he a Web att^chfed' TV; a personal' digital iassistant, 
^ " or a cell-phone or pager v^-fh display capability^ and io forttf, anti PC 51 , which can -be^'a . 
Intel/Windows-based compxiter. The specializefd'end-devices 'are particularly :^ppropri 
applications such as*telemedi cine ortemote 6onsultati on/' ' '' v:; ' --y ^-- - '^^- -^--'^ -...^ ^ 
20 ' ' • In the pi'efen'ed-Java^ languia^felm^hE^ 

' components of substantially equivdlent fuhctiori, principally a 'Java-erlabled HTML browser 
and a Java"^ ORB, in addition to necesskry system' sbftwkre^ td^r^ in the memories of 
end-user devices,^ from cell-phbnes^ td PCS. Herein,' aifHTML; brb v^^fet progrgffn refers to 
• Client software that-^fim'ctions to retrieve and display fequested'HTKffi'9ociim6^ an 
' 25 - «TML server according to ^e TCP 

' includes an embedded Java^ applet, the'fcrowser automaticaity dawfiibacis the applet's Java"" 
byte-cbdes' from an applet store and execute them in its Java*^ virtual machine ehvironment. 
' ' . ' - Alternatively, mstead of a browserprogfani, a sepa^^ 
^ * • of similar function, preferably also vvrrtten iri Java'^, cari^ be liSed together with an installed 
30 Java"" virtual machine. Such a stand-alone program would include similai* end-iiser device 
' display management capabilities, screen definitions similar' to any do wnloaded HTML pages, 
arid intenial routines with fufictiori equivalent to any downloaded Java"" applets. 

It is preferable that the browser be capable of communicating information, for 
example, its type and version number, so that its capabilities can be determined from stored 
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. infonnation, preferably in the persqnsaizaition database., Siinilarly,-the IP address of an end- 
user device can be iised to determine its capabilities and th^xapabilities of its display from 
stored information keyed by IP address, again, preferably, in. the personalization database. 

In detail, Fig. 3 illustrates browser program ,52 designed for specialized device 
5 50 communicating yvdth middle-tier server . 65 over communication path 5,3, and browser 
^ program 54 desired for PC 5 1 cominunicating with HTTP server 65 over communication 
path 55. 

Object-oriented Java*^ applets 56 and 57, running in a Java"" virtual machine 
environment provided in the respective, browser .programs, interact with,middle-tier business- 

10 server objects 67 to respond to jiser requests. An alternative to using the browser's virtual 
machine it to use browser plug-in technology available from Sun Microsystem's 
(http://vmwjavasoft.cqm/Firoducts/plugin/). This technology allows use of Sun 
Microsystem's most recent Java"", runtime environment instead of the browser's default 
virtual machine. In partipi^ar tliese applets receive end-user requests, including those for 

\^ . deteri;^e which by^pess-seryer object that.can respond to the request according 

to the request's type, remotely invokf methods of that busiAcss-seryer object, and receive the 
results returned,- including any CPR data. Personalized views of the requested data,- for 
- .ft ' exampkiresidenf'iit buffers 58 and 59, are then displayed. 

. - : ' ' Data presentation and per?Qnalizati which are important to this 

20 , invention and are siibs^qu^i^tly described in detail, alternately either can be -performed 

entirely l?y the ^i^iness-seryer. object pr can be shared between the business-object server and 
the object-9ri^nted .e?id-us(2r de^^ in the case of more capable end-user devices. 

.. , T^,?^^ ^ks personalize displayed. results aceprding to .end-user characteristics and format 
them according to the capabilities ofthe end-user device.. . ^ . . 
, .. . - V , . Remote inypcatio^.of iniddle-tier bjisiness-server o^bject methods by the - 
pbjpct-qri^nted. end-user .dpyic? applets, are automaitically managed, as previously, described, 
b^.the communicfting OI^A, ^such^^jJgya'T, ORBf^fiO and:6J resident.inthe.end-user 
. memories, and Java"" ORB resident in the memory of the middle-tier server computer 76. 
The invocations can advantageously employ either.the, static or the dynamic CORBA 

30 interface, .or pther CORBA facilities and features- . ... . . , ■ 

, . I.Ti the preferred enibodjmeijt, inter-ORB communication utilizes the TCP/IP- 
based protocol IIQP, Since browser rpi;ogram communication is also TCP/IP based, all 
communication between the end-user devices and the middle-tier computers, for example 
over communication paths 53, 55, 62, and 63, can easily share a single physical network, 
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since TGP/IP protocol stacks (not shoAvn) residfent in the memory of each computer and end- 
' user device multiplexes the commuiiicatron paths onto single links. ■ ' 

■ ■ • ' - • ^ As also described subsequently 'with respect to Fig. 4, the software functions 

' illustrated in Fig. 3 in the end-user devices are established after successful end-user logon. 
5 • For logon purposes; the browser program retrieves HTML logon pages, obtains the user's 
' ' authenticating information; and verifies it with a middle-tier security server. Preferably, the 
logon pages include object-oriented Java^ applets which remotely invoke authentication 
methods in security-server objects 70. In tone alteniative, following successful 
authentication; one or rhore HTML pages are retrieved by the browser programs, direct 
1 0 downloading'of Java^ applets 66 and 67, and commence end-user interaction. ' 

Personal smart cards can also be used in this invention to provide certain user 
authentication information as well as certairi' personalization ihiformatioh (in the case where 
the end-user device shares personalization tasks). Smart cards are credit card sized devices 
which contain a processor, temporary memory; and jSeimaneht memory, a'certain portion of 
1 5 - which is- secured from tampering' or unauthorized access. Authentication information' can be 
stored"in the secured portion, while general personalization information can* be stored in the 
remainder of permarieht memory. ' ' " ' - * - ^ : . 

The Middle Tier „ r-^^r^;^^- - 

Middle-tfer software* furicti oris; illustriated iii Fig; '3, respond to remote'^method 
20 'invocations fifom end-user device applets vvillhVanoiis requested results, including partially or 
entirely formatted aii^ personalized CPR data fetcfied fi*orn baik-end data-server* objects. 
' Because of the location transparency of the distnbuted object-oriented software 

■ • 'infrastructure^ the various middle-tier "and other oBject system fonctiohs can be allocated 

freely to one or more computers. 

25 - - ' Middle-tier software components are now sequential!^ described. Security 

server 70 includes objects providing methods fbr user kiitheriticatiori. ' Logori HTML pages 
gather user aiithenticationlnformatiori^ Such iais' user-id arid password. 'Preferably, Java^ 
' applets,' also part of the logon pages, reniotely invoke the authentication methods with the 
gathered authentication 'informatioii as parameters: Suc'cessfril authentication^ allows 

30 completion of logon and commencement of interactive lisage; unsuccessful logon blocks 
further response'from the system. Various kinds of user authentication information can be 
used in this invention, including information read froni a user's' smkrt card by an end-user 
device' card reader or bidmetric information obtamed*"by a biometric scanner. 



BNSCXDCID: <WO 0057339A2_I_> 



wo 00/57^39 . i;CT/EP00/02753 

. t..- B^"iess-server Objects 67 are renjotelyM^^^ 

and 57 to process the various types.of user requests,, including request^. for -CPR .data, for data 
entry, for alerts ^^d reminders, and„for decision,support functions. Requests processing is 
summarized iiere and described in greater detail in connection with the business objects 
5 themselves. For all requests, the business-server objects proceed 9nly after first ascertaining 
that the user has the authorization or access privilege!S needed to make the request! 

First, for CPR data requests, the business-server objects, after detemiining user 
access privileges, retrieve the requested and authorized data by remotely invoking methods of 
data-server objects resident in the memories of back-end systems. They then, optionally in 
1 0 cooperation with the end-uspr device applets, personalize and format data for -display. In one 
implementation, each business object demultiplexes requests for all types of CPR data, 
directing each to the appyppriate data-server object.. Here, the end-user device applet is 
simplified in that it needs to address a CPR data requests to one* class of business-server 
object. In another iniplement^tion, each type of CPR datais retrieved by a separate, class of 
15 business objects. Herp, the ^nd-;user device applet itself must direct the request according to 
the type of CPR data; requested. ., . , 

...... - - For data entry, requests, perhaps conceminga patient of an end-user, the 

-'1 irbusmess^^Sei^ checking,, retrieves^jthe appropriate data-entry forms or 

instrucdons^frpm-the^^^^ object, provides these to the end-user 

20 applet, and return^ pntered data jQ the^responsible server object. .In, some implementations, 
. ; ^ bpfipess-seryer p^^ . , _ v, - : 

• rj . r.'^: ^.^^i^ ^^^5*?^J?5^^^ also>provide decision support capabilities .to authorized 
_users. .Fpr suchje^ input infprmatipn.from an 

end-user and then ipvp^ 4edsipn support processing by,: for example, medically-directed 
25 expert systems. . , . - 

. . . . • _ ?^?!^?^?:^^^F^r^;^J?5^ 5:^5^sp generate alerts and reminders for a requesting 
en^-user. Here, in one embodiment,, Ae business^s^ryer object reviews CPR data for patients 
associated with that end-user apd issues appropnate alerts and reniinders. Alerts can be 
- -:^^^^f^^^.^ ^y OT^yipS ^decision suppprt processing to CPR data. -For example, a physician 
30 can be alerted to possible drug, intjsractions.based on drug interaction decision rules applieii to 
CPR data including current medications for a patient being treated. : .Reminders: can simply be 
end-user entries placed in the^patient records fo . . : — ' 

- . Finally, the system of .this, invention is.-9pen tp the addition of pther. types of 

end-user requests in a routine manner. To do so, end-user applets can be modified to provide 



BNSDOCID: <WO 0057339A2_t_> 



' - ' 'wo 00/i57339 j ^ PCt/EPOO/02753 

> for the display of the new type df request and for entry of its associated parameters, and a 
- new business-server objecfcan be added to the middle-tier to process the new request, 
perhaps in cooperation with data retrieved from back-end data-server objects, " ' 

' ■ HTTP server 65, HTML store 66, and applet store 67 Have been previously 
5 * described in connection with first-tier components. Rules engine 68; mle modules 71 and 72, 
and personalization database 69' are subsequently described in connection' with the business- 
server bbjects themselves. 
The Third Tier 

Persistent CPR data of all types, for example th6se types previously 
1 0 enumerated and other types that may be become useful, are stored on back-end server 
computer-systems, which make the stored data available as data-server objects, such as 
system 77. The business-server objects of the middle-tier remotely invoke methodis of data- 
server objects 73 resident 'in memories of back-end computers during the processing ^f their 
own methods, which were, in turn, remotely invoked by end-user applets resident in the 
1 5 memories of the end-user devices. Where the data-server objects are remote, this invotatibn 
is managed by middle-tier resident ORB 64 communicating With third-tier resident ORB 74. 

Third^tier data server-objects- can either be trompbnerits of a system initially 
designed to be object-oiiented or they caii beiegacy systems With inteiface soffware 
' "wrapper") for transforming legacy programming interface's irito" bbjfect-brierited. method. . . 
20 "' interfaces: Such object "wrapping" is known in the; ifti'^S^ 

application 09/096694, filed' June 12, 1998.* Legac^'sy sterns 7-5 include, for 'example, Picture 
: - ' ' Archiving and Gommunication System (P ACS)^ " Hbspi^l ' Infoniiation System (HIS), 
; : • Radiology Information System ^S), Cardiology Information* System (fclSj, 'laboratory 

"■- system, etc. Details of such object-wrapped, legacy' s^steA^ ai^ei rt^^^^ 
25 Business-server Objects - Rule Processing 

- • ' " In the next two sections, business-ser^^er object pmcessing is presented in 

; detail. In the following tw6 sections, the dataL ContfoUing this processing, namely the 
> : persbhalization database and' the rule's, are preserifed in detail. 
- • - 'Business-seiVer objects processing is prrf^ User requests and 

•30 theirassociated parameters 'are processing accordiiig'to r^^^ 

' recommendations resulting from application of stored rule^ to eiid-user personalization data. 
The personalization data includes at least information cdncerning^tiser Characteristics, such as 
user role and user privileges, and concerning user environment, such as the type of end-user 
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device, the network link to the device, -the device'_s display capabilities, browser program 
capabilities, and the room location. ... .... 

Business-server objects use rules to guide the often complex and frequently 
. changing criteria by which users are authorized to access system, services, and to access 
particular CPR data items. Rules are advantageous for jsuch.decision-making because, at 
least, they are a known, niodular, and extendable programming method for decision making. 
First, it is known how to express such criteria in rules, for example expert-system rules. 
Second, rules can be modul^ized so ^at changing decision criteria can be met by routine 
modification of specific modules without any need, to modify code. Finally thkd, with 
appropriate additional rule modules, the same rules processing, can provide decision support 
services. 

Although rule-based processing is preferred in this invention, it vvill .be 
apparent to one of skill in the art ^.at tl>|s. invention can also employ similar known, modular, 
and extendable decision-making proc?ssuig methods, or combirmtion of such.me.thods, 
known in the artificial intelligence arts. For example, the effect-ofrules processing herein 
can be achieve^ by methpds based on a first-order predicate Ipgic knowledge representation, 
and associated inference engine. . See,, e.g., Russell et al., j995, Artificial Intelligence - A 
■Modem-^pprnarfe-PrpntirP-Hgl^ '7.^n 

i . preferred embodipent empjo.ying jule-based processing, piles used by 

the business-server objects ?re, preferably ^exp^essed with a, limited set-of programming • : 
language constriacts express?fi in sta^^^d syntax, jncluding^variables, boolean jexpression, 
and statement inclu5iing ':if,thep-els^ statements, assignpeirt.statements, and rule invocation 
statements. For exanip|e^the itifPTOial access rule that "if the user is a physician and if the 
user is the physician of the. COTenJ patient then the user can ^ee . the records of the patient" can 

be expressed in a precise syn.tax in the following manner:. , . - , 

.RULE SeeRecord { .. .. . .. . . . .. 

Valueproperty case; . , .. . , 

• IF.(user.^ction=.';phyacian^:) AM)-: . 
^ t ., (patie.nt.physicianir=user) .. . .. 

.... . . . , . THEN. {,approved.value?= true; }•;, - 

ELSE { approved. value =false; }j .'. . • . . • 

Exact rule, syptax vaqes depending on the exact rule; ianguage. aod the rules 
engine used in a particular embodiment. 
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- ' Rules semantics is siiiiply related 'to the understanding of their syntax common 
to those of skill in the art. Each rule is typically an "if-then-else" statement, which can be 
• optionally nested. Rule evaluation- begins with evaluation of the Boolean "if-condition" 
based on data values input or assigned to rule variables. The "if-theh-else" of the rule body is 
5 -* evaluated and- any statements' in the "taken" branch are performed. For example, performing 
assignment statement routinely sets the values of one or more rule variables to the value of an 
expression. Performing" rule invocation stiatements routinely chain "rules, so that a first rule 
can invoke a second rule. The rule to be evaluated next can be' selected sequentially from a 
list of rules, or according to a priority assignment which can be dynamically updated, or by a 
10 . ' rule invo'catidn statement. - 

A rules engine evaluates rules presented to it. In one implementation, the rules 
engine simply interprets rules presented in a plain-text form. " 

* Generally, rules are stored separately from the business-server objects inPrule 
databases, or rulebaSes. Needed rules are retrieved from the rulebases by business-server 
15 objects or the rules'ehgihe as needed. ^ , ~ - . 

Further, related rules are advantageously g^oiiped together into rule-sets; 
. related rulersets are also advantageously grouped together into files known as rule' modules. 
Grouping rules into rules modules is advantageous for the following reaiSonsI'^Fif^^^ - 
; unde&irable -interactions between- certain* rules can" be^ avoided by putting those interacting 
20 rule^ iiitb separate modules separately pfesented to the rules engine. Second, rule modules 
: and i:ale sets caih be assigned priorities which helpk to order their evaluation. Third, smaller 
rule modules improve performance because only a subset of the rules and object are used at 
. ■ any. given time and need to be stored in memoiy. Fiiikiiy, rule modules also facilitate rule 
.r. update and maintenance, since each rule module can be' maintained by the most 
25 knowledgeable person. For, example, administrator's can update policy and practice rules; 
domain experts can update decision support rules; and tisers can update' their personal rules. 

Thus, instead of having one bulky cumbersome rule module for a whole 
medical institution, several separate rule modules representing different aspects of the 
institution's policies and practices are preferable: Accordingly; related rules for 
30 personalization and deciision Support are grouped into a plxirality of smaller rule modules 
havingdifferentfunctions";- ''^ - " * . j v ^ 

Rules used in this invention can be programmed with various commercially 
available-knowledge-based application generators, including, inter alia, ART*Enterprise 
(Brightware), LiveModel (Intellicorp), Elements/A(ivisor (Neuron Data) and AionDS 
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. (Pja^^ Technology). , Eacji pf! these have their oyra syntax -for specifying rules. 

.Also, the i^den syntax has been.deye?loped for general uses in ^medical knowledge • 

applicatiop, and has been adopted.as a standardfor health know See, 

e.g., http;//wwwxpmc.columbia.edu/resources/arden. - 
5 _ A_ preferable conamercial knoyvledge-based system provides graphic rules 

editors for defining new rules and mpdifying existing rules, so that even non-programmers 

can view and update rules. Such a product also provides tools for checking the consistency 

of the rules. ^ 

Business-server Objects - Processing . ... 

^ ^ . . . ....... General system processing, and its distribution among the sy^tem.tiers, is now 

explained in detail with reference to Figs. 3 and 4, in which thejabels "IT", •*2T", or "3T" 
denotes processing that pcpurs at the first tier, the second tier, or the third tier, respectively. 

At access step . 80, initial accesses of an embodiment pf.this invention by a user 
causes the browser; program, which is resident in the first-tier end-user device, to contact 
1 5 HTTP server. 65 at the second.tier,. whereupon the primary, or root^ HTML page: is • 
^ ^ automatically downloaded from HTML store 6^ at,first download stepr.8 1 , Next, at second 
download step 82, the end-user device applet referenced in this primary HTML page is 
' - . doA?^paded^om applet store^67,^d applet execution is initialized and started in the 

browser program. From^this step pn^ until end-user logoff, the object-oriented Java^ 
20 , applet jnanages the u^er-interface in die.end^user4^yice and responds to user requests hyK L. 
, maldng reinote invocations of rne^^ 

; - ' - , B^^r^^^^^^S^i^^^^^ ^PPl^t.-is authentication step 83; during 

/^hic^ the iiser is^a^thent^pat^^^^^ The endr^user applet remotely invokes 

auth^ntication;i^e^^^ in secppii^ier securi obje.cts 70. If the security-rserver 

25 objecp do not autljentipate^the user,. appropriate security, actions. are undertakeir;to safeguard 
system integri.ty.and confidentiality. Fjuriher, system security is. provided by well known 
protocols which use digital signatures, authentication, and document alteration prevention 
techniques... , ^ ^ . ^.^ ^ 

. If the user, is authenticated, processing continues with rsubsequent steps 84 to 

3-0 94^ whiph impleipent the juseprequestrprocessing loop.. This loop is executed until user 

logoff is detected at test 94. y^Aer logoff, at step 95, the end-user deyice returns to a neutral 
state. ... - . . : 

' ^ .. . The user-request-processing loop begins at wait step 84,- where it waits for a 

user request. Upon entry .of a user request, after which the end-user device applet gathers the 
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request t5^e and associeteffparffliieters; and determines the appropriate bxisiness-server object 
to service request of the input type:' During 'remote invocation step 85; the request and 
parametetS are passed from the first-tier "end-user device applet to appropriate second-tier 
business-server object 67. ... 
5 ' - '• ^ Each second-tier fcusiness-server object generally processes remote method 

invocations according to steps 86-90. First, at read step 86, business-server object 67 reads 
stored rules modules that recommend the processing of the entered request type/ Rules 
modules of this invention are generally considered either as belonging parf to the decision 
support rules module family 71 or to the personalization rules module family 72, each of 
10 these families havinfg flie exemplary members illustrated ih Fig/3. ' These rules modules and 
related request types are -subsequently described in more detail. Rules modules "are read in 
the order of their assigned priority for efficiency and for control of the processing order. As 
the business-server object reads rules of each rules module, it also reads from the 
personalization database values for personalization data type^ referenced in each rule and 
15 pertaining to the particular end-user. This' read accesis is represented in Fig. 3 by paths from 
business-server"6bjects 67'tb plefsbrialization databaie'69 and'td rules modules families 71 
and^72: '^'^ 'r' " - ' ' .y 

- - Therefore, at call step 87, the business-servdf ol^ject read^raIe>modules 

* referenced personalization database values'." In'^is step, the biiSiness-server bbje^^^^ read 
20 : both rules primarily' related to autfiorizin*g'ahd ^atisfyirfg thd'iehtered-usier i-equest as well as 
personalization and'forinatting rules knd referenced data. 'Alt'feftiativeiy, it can defer reading 
' . the latter rules arid data until they are needed at fdrniaf steii'90.' The business-server object 
then calls, or ofliervmaairfangeisto pass, the retrieved rules ^d^the user's personlaliSzation 
; data-type Values to rules engine 68 for pfocessing.' B^aisfe 6f mle c*haining,''m^ 
25.-. -passed'to riites engine 68 may requires itohera'ccess to additidnal^' rules modules' and 
■ personalization data-type'values. THis-acceiss isiUustrat^d in Fig. 3 by paths from rules 
. . enginis 68 to-pisrsbnatization-database 69 anti'tb rules iriedule families 7! and 72. 

Aspects of rule-based server object processing is also illustrated in Fig. 2. 
: Therein, nriethbds-bf server object 1 10 illustrated readrules modules 111 and pass them to 
30 rules engine' 112-, which returns processihjg feconmtendatioris to these methods! Because of 
' • • rule chaining, it may 1)6 necessary for rules engine 112 to directly read rules modules 1 1 1, as 
illustrated. One of skill in the art will recognized that this invention is not limited to this 
particular rules access structure, but comprehends other' access structures that make needed 
rule modules and personalization data"type values available to the rules engine! 
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Returning to Figs. 3 and 4, test step 88 distinguishes two. processing cases 
depending on the type of entered request and recommendations returned by the rules engine. 
In one case, no access to actual CPR data is needed. For example, in the case of a CP^R data 
request, th^ rules engine may recommend denial of the user access request. In th.Q case of a 
5 decision support request, all needed data may be entered as request parameters by the end- 
user. 

If CPR data access is needed, at remote invocation step 89, business-server 
objects 67 make remote method invocations to methods in appropriate .third-tier, data-server 
objects 73. Data-server objects 73 access CPR data, either directly from object-oriented CPR 

10 database systems or indirectly through wrapper code froni legacy CPR database systems 75, 
which are typically non-object-oriented. 

In either case, at format step 90, the data or results are personalized and 
fomiatted according to recommendations returned by mles engine 68 upon processing 
personalization and fomiat related rules m^ These modules and data can be 

1 5 either read in prior step 86 or deferred to this step. For example, a formatting i 
recommendation may be to format a medical image at a resolution of 640x480. 

. - ^ At return step 91, the personalized data or results are returned to the first-tier, 

r : ,^- -end-user ;d^^ completing the remote method invocation of the business- 

server object initiated at step 85. Finally, returned data or results are displayed to the end- 

20 . user at display step 93. ... 

For capable end-user devices, such as PC 41^ certain^ata or results formatting 
operations^, principally machine specific formatting operations, can be advantageously off- 
loaded to the end-user PC. In tins case, also resident on PC 51 would be certain local rules 
modules and personalization data, typically machine specific formatting rules and machine 

25 characteristic data, and a local rules engine, Preferably,. the local rules .are cpded in Java^- 
and are downloaded as an applet. End-user dpy ice applet 54, before final displayv would 
interact with the local rules engine, in a manner similajr to the interaction of business-serve 
objects 67 with rules engine 68, and wpuld further format returned. data. or results according 
to recommendations derived from the resident rules and returne.d,by the local; mles engine. 

30 For example, an entire.high-resolution.medicalumage can-be-downloaded.to PC 51, with final 
. formatting at the resolution of the attached display, either as a whole,or in segments as the 
user pans across the image, deferred tq the PC, For a high-end end-user workstation, this 
alternative advantageously shifts processing load away from. the second-tier server to first- 
tier end-user devices. 
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"^^ Personalization Database ' " 

' The personalization ditabase'contairis values for data of varied types that are 
referenced by the stoi-ed system rules that guide business-server object processing. 
' Exemplary data types 'typically present in the personalization database are discussed 
5 individually as in the classes that follow. 

It will be understood by one of skill in the art that the foUov^ng list of classes 
and their categories and subcategories are not limiting, and other classes and categories of 
data may be advantageously stored in the personalization database. 
USER ATTRIBUTES CLASS: 
10 ■ Data of the user aftribtites class indicates the relationship of the tiser to the 

medical institution or to particular patients, as well as the user*s interests and preferences. 
Preferably, users are divided into the categories of staff, patient and visitor, with the 
iFoUowing subcategories: 

- Staff (physician (department, functioii, specialty, interest, education, level of security, 
1 5 favorite browser, etc.), nurse (department, function specialty, interest, education, 

authority for information access, favorite browser, etc.), administration (department, 
function, interest, etc.)). ' * " -r. ■ 

Patient (inpatient, outpatient, department/section (internal medicine^ surgery;- emergency 
' ' " room, cardiology, etc.), favorite bi-owser^.' ' " \ 
20 - Visitor (for which patient, first time, regular, etc.). " 
^ • ' USER PRIVILEGES CLASS: ' " ' ^ --^^ - :^ ' ^ 

' " ' ^ Data of the user privileges class indicates CPK data access allowed to the user. 

* Preferably, this data are orgaiiized into the following ^ 
' Write access or read access, and to which data. ^ • - . . - l: . 

25 " Full view to all CPR data of airpatients. '"" 

- Full 'view to air CPR data of some patients. — - - . - 

View only to CPR data related to user citegbry and interest of some or all patients. 
Minimal vi^w to' CPR data of some of air patients ^ - . 
• No view to any-patient CPR data. 
30 COMPUTER: AasfDNETWORXCHA^ " ' " ' ' 

^ ■ ' ' Data of the cdmpiitef and network characteristics class indicates the hardware 
'and software characteristics of the user's computer arid of the network connection of the 
computer to the system. Preferably, this data are' organized into the following categories and 
subcategories: 
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- Type (SUN (Ultra 1, Sparc 20, etc.), PC ^^^^ ^ 

- Operating system GJnix (flavor of Unix), Windows (83, 95, NT), MacOS). - 
Support for audio and video, if any.. . . 

- Lowest bandwidth, link to server (bottleneck link): ATM, fast Ethernet, Tl, Ethernet, 
ISDN, phone line, wireless, and so forth 

DISPLAY CHARACTERISTICS: 

Data of the display characteristics class indicates the characteristics of the 
display of the user*s computer. Preferably„this data are organized into the following 
categories and subcategories: 

- Spatial resolution (2Kx2K, IKxlK, XGA, SVGA, VGA, etc.)., . . • 
Physical size. . . r 

Monochrome or color. 

- Modulation transfer function. . - , . 

r Amplitude resolution (number of levels of gray scale and/orof color). 
BROWSER CAPABILITIES CLASS; . .. 

Data of the browser characteristics class indicates the .software capabilities of 
the browser resident in the end-user device,.. Preferably, this data are organized into tije 
^follomng'catfegories and subcategori^ 

- • Whether or riot Java*™ is enabled. 

- Whether or not ActiveX is supported. _ . - • . r 

- WWch versions of HTML axidHTJP.are supported. . - 

- Which plug-ins are, supported. , - . . 

ROOMCHAJlACTEiaSTICS^^^ . ^ 

. _ ^ ^^^^ of.|he ^opi^ .G^^ 

current room locatiori. Preferably, this data are organized into the. following categories and: 
subcategories: _ , . _ 

- Function of pom (patient room, laboratory, fihn reading, library, public room, private 
office, home,,^ etc.) 

Lighting conditions (dark room, bright room, , etc,) - . - ^ 

- Audio characteristics. .(Joudro.om^ quiet room, -etc.) . _ 

- Audio display allowed. . , . 

Information of these classes and categories is stored in personalization 
database 69. This database advantageously iricludes a plurality of storage structures 
appropriate for the types of -data being stored. Persistent data, which is useful across several 
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user sessions, can be stored either as a structured database or alternately as orie or more files, 
or certain portions can optionally be stored in a user smart-card. Traiisient data, which is 
useful only for the current user session, can be stored as convenient, perhaps £is in memory 
- data records associated with the user session representation. Accordingly, the storage of 
5 personalization database information is preferably adapted to the type of information and to 
its persistence. 

Information is entered in the personalization database by various methods, 
including, inter alia, through forms and from dynamically available session information. 
With respect to the use of forms, the system can query a user upon first accesses to enter 
10 persistent self-descriptive information': This information can be updated on user request. 
Preferably, the system will display a HTML form, perhaps with Java^ applets, seeking 
information about the user's department or section, function, specialty, interest, education 
level, default browser, and so forth. Further, by using further HTML forms, the user can 
enter details concerning persistent preferences for screen fay out, help presentation, printing 
15 formats, presentation of alerts and reminders, and so forth.' In a similar manner, system 
- - administrators can enter sensitive persistent data controlling the user's authorizations and 
access authorities so that they arfe consistent With the medical institiitions policies.and:-" 
practices. * . ' * -v'■^■^-:4vr^"''^■-^^^;■^>'^^ 

Environment profile information is obtained from the IP address of the client, 
20 client-server browser communication, smart cards, active badges, and so forth! IP addresses 
of clients requesting information from the server,' where diey'afe statically rather than 
dynamically assigned, uniquely identify the end-user'ctevicer In such situations, the IP 
address of the end-user device is automatically detected b^yme'web server wheh a user logs 
'- on^ and then computer, network, and environment k^bhiiiiioh' is retrieved from a database or 
25'- ' ^files;at the second-tier server which includes such info^ation indexed by IP address. 

Thereby, the IP address can be used to identify the computer type (e.g. SUN, PC, MAC, etc.), 
. : itsTadd-on capaibilities' (e.g. sound card; video decoding hardv/are, etc.), its lowest bandwidth 
connection link to the web server (e.g. ATM, Ethernet, ISDN, wireless, etc.), the resolution 
of the display to which it is attached'(e.g. 2Kx2IC, IKxlK, XGA, SVGA; VGA, etc.), the 
30 location of the computer (provided it is not mobile), arid coAstrairits imposed t'y tHe location. 
System administrators of the hospital's computing facilities would update siich system 
resource-databases as necessary. ' ' " ^ ' ' 

• ' Altemately, the browser program running* in the end-user device can detect 
• • device and browser capabilities and can coriimunicate theise to the second-tier server.'* Thus 
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the previously listed computer, add-on, and display capabilities, as well as browser 
capabilities (support for Java"^, ActiveX, versions of HTML,^?ind.HTTP, plug-ins, etc.), can 
be. made available. Tliis is ppssible even \yhere the IP address is not a .reliable indicator of 
such information. Alsp, information m a smart card, carried by a user. can be read to provide 
5 certain user attributes as well as to prove u$er identity. . . 

Rules Modules - Personalization Family , . . . 

The rules of this invention, which are separately stored in rule databases and 
are retrieved by the business-server objects and the rules engine, are advantageously grouped 
into and retrieved as rule modules, which are collections of rules and rule-sets directed to 
1 0 similar situational analysis. Further,^ for purpo^ses of description, the rules modules are 
, , . assigned to two families of rules mpdules,.namely decision support rules module family 71 
(Fig, 3) which are directed to providing decision support services to end-users, and 
personalization rules modiile fanaily 72 which are directed to personalizing and formatting 
system data and results. 

15 ^ The personalization rules module family is described fu-st followed by the 

decision support rules module faniily.^ The following, are examples ofconstraints imposed in 
personalizing .thC: content:, ^ . ^ „ 

t, as^cardiology, of a physician user,shquld,be taken into account so that 

the physician receives only the news and information which is likely to be of interest. 
20 - Iriformation should onl^^ provided to users with sufficient access privileges. 

; „ : Rooms that are meaiit to be^ guiet rooms such as reporting rpoms or library locations 
should not be exposed to^end-user 
. . . " , . A ^on^P^ter that dpi^s not have . a^ sound card should not receive audio files in any case. 
- A laptop v^th ajpw-sp^^^^ a small screen should not be exposed to large 

25 movie files or large images. . ^ ; . t r : - -: - 

. - . A browser that does npt support ActiveX should not be exposed to ActiveX components. 

Personalized, pontent is not only poreinteresting and relevant to the user. It 

also inakes more efficient usage of network bandv^dth and system resources, reduces server 

load, and can also reduce document retrieval latency. , . . r 

30 , . . : Accprdjngly,. personalization; 

least an averts & reminder rule rnodule, an access privileges rules module, a platform rules 
module, a graphic user interface ("GUI") layout rules module, a help rules module, help 
rule module, an order & forms rules modules, a printing rule.module,-and such other 
personalization rules modules as a. medical institution finds advantageous. ^ . 
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ACCESS PRWiLEGES RULlSS MObutE: ■ ' ' ' 
* The rtfes of the access privileges 
- - - * • authorized to' view which information concerning which patients. First, access privileges 
' ' ' depehd on federal and sWte regarding patient confidentiality law. Each medical institution 
5 hospital may also have local protocdrs for ensuring patient confidentiality, data integrity, and 
security (digital signatures, authentication, and document alteration prevention techniques). 
The system administrator of the hospital is responsible for maintaining such policies and 

-Jo, 

rules for information access. 

Access privileges also depend on the' user function, role and relationship to the 
10 patient (i.e. patienfs attending physicikn, consulting physician, attending nurse, etc.). For 
example, not only do different occupations/specialties need different "view's^' of the CPR 
which are tailored to their needs but different patient relationships may influence the level of 
detail presented in sensitive kreas^ For example, all physicians who treat a patient may see 
that the patient is undergoing psychiatric treatment, but the details of any psychiatric . 
15 ' treatment may be H^itwable only by the'attendihg psychiatrist and the patient. Also, access to 
records^foi- cer^tin' "VIP" patients (f)oliticians, actors,^ etc.) may be further restricted than for 
normal patients, due to the increased potential for adverse publicity and blackmail. . Patients 
should be able to see their -owti CJPRi,'in' full detail. Tfee samfe is .a^so-tnle^f6^?^egal gxiardians 
of underage or legally ihcapable'patients. ' ' ' * ' ; ' " , J * - ; ; . 

20 ^ ' All users should have'a'defiuli: log-in which has minimal privileges, but is 
based oh location: Therefore', any health care ptoVider inside a hdspital maybe able to see a 
summary CPR for any in-patient without a SpfeciaHo'^-tri (dth^r tlidri id'eiitrfyirig themselves 
as health' care providi^; for exaniple via smabt card ID): Ho^^ever^ this'ca^^^ would not 
' be available- from outside the firewall guarding fee infegfit^'^of' the^'iritranet. ** 
25 PLATFORM RULES MODULE: . - r : - • ^ 

• ' ' • " The" rules of the platform rules Module 'detdriniries hoW content should be 
• personalized formatted for'a particular efld-usef d^vibe Coniieited 'bri a particular network 
- link.' -Such personalization and fotftiattiiig is ihdependent of^iiser requested personalization 
because many users (physicians, in pfarticular) may ha^e nlafiy types of equipment and 
30 ' network link^i elg; at-the office, tfie hospital,'and"at horrie, A^liich have widely varying 
' - abilities. Further; the system can include end-user devices which are riot assigned'to 
. - ' particular end-users"for public-use,' e.g., by referring physicians visiting their in-patients. 

'* ' 'Therefore, the business-server objects, acting c5n recommendations of the 
platform rules module, personalizes and formats information presented to be consistent with 
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an end-user device's location and capabilities. As discussed, some information on these 
capabilities is gathered at user login. The. content can be dynamically, generated and 
automatically customized to match the. capability of the client browser, display, and , link 
bandwidth. 

5 . , . For example, images, and sound files are personalized and formatted (fiill - 

resolution or minified) and compressed for transmission (none, loss less, .lossy/quality) 
according to the link bandwidth and the capabilities of end-user devices, so that a user need 
not wait for large transfers at locations with low speed connections. If the display of an end- 
user device can not handle high-resolution images, then low-resolution images are presented 
10 on this device, even if the user has requested otherwise. Likewise, if the network connection 
of the user is slow, then lo\v resolution images shoudd be transmitted, vinless the user has 
indicated acceptance of the necessary wait for full resolution images. 

Concerning specifically images and video, end-user devices with 
low-bandwidth connections and/or low-resolution displays need low-resolution images and 
15 lower fi-ame-rate video. When considering heterogeneous networks the lowest network 

bandwidth link between the server and the clients is the limiting factor. Scaling and layered 
video coding scl^emes M-e one method which can be used io multicast one single compressed 
• ■:;vvideo-streaj^^^ hpterqgen^otK. networks, computers, and displays. The routers can then 
send the appropriate numbCT. of t^mpjesse video layers to the appropriate machines for 
20 ^ software or hardware decodirig. Fpr example„a high-end workstation with a high resolution 
display and high bandviidth connection will receive the base layer plus all the enhancement 
layers. An intermediate computer with a moderate resolution display and a moderate 
bandwidtii .cpnnectioij.pgm receive the base layer plus some of the enhancement layers. A 
, Jow-end, >V9rkstation witti_a,lp\y,resok^^ display and a wireless connection, however, will 
25 receive only the basejayer. , . . , :. . ,, u... 

Gyi LAYOUT RULES MQDULE:.^ ^ . , . . .. 

- . T^^ ,'^^.^. 9f^^*^UJ (graphical user interface) rules modu^^^^ 

. contept to be presented should be.arranged on. th? , display screen of an end-user device for a 
. • .particular end-user, "Diese rules; can; interpret user, preferences stored in the personalization 
30 database. Altematiyel.y, a iiser may. personalize .the rules thernselves-; . ; . . - . - 

Rules of this module can determine the overall layout of an. end-user device 
screen display. For ex^mple^. screep. displays can be partitioned to accommodate different 
information categories in different regions. A. large portion of the screen will be reserved for 
personalized and formatted information requested by the user. Another portion of .tiie screen 
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Will be'Tesefved for general information which should be seen by everyone at a medical 
institution.' Finally,' a'third portion will be" reserved for personal information, such as, for 
example, the web sites and content which the user visits most frequently. 

Further, rules of this module can determine how these screen portions are 
formatted in^ detail. For example, a user can specify a flag to view nimierical results in 
tabular form or in a graphical plot. The user can request hot to view images. The user can 
specify the positioning* of information items (for exaniple, show the present lab results next to 
the previous lab reisult, with the most recent lab results on the left). 
HELP RULES MODULE: 

The rules of the help rules m6dule determihes 'how the on-line help system of 
this invention is personalized to pfrovide the most efficient assistance to an end-user. 

Preferably; the help and explanation provided can be personalized based on 
the level ahd experience of the user. The user information that is stored in the t 
personalization database can have a "liser level" attribute for each user to differentiate expert 
CPR users from novice ones. Alternatively, the system can use the audit trails and/or track 
users to -figure out the level of each user. ' ' ' 

Also preferable, is that the rules of the help rules module adapt the screen 
display to create a personalized help system. Which helpvsystem eomponeht^a^^^^ 
can be context sensitive and depend oh the task that the user is performing (e.g. viewing, 
reporting; ordering; updatihg, etc.) and the information category that being acted on (Lab, 
phamiacy, radiology, btc.). ' ' ^'.^ - 

ORDERS & -FORMS- RULEiS MODULfi: " " • ; : i' . . v : . 

: = ■ -\ : The rules of the orders & fonns' rui^s niodule detenriiries which users have 
privileges to access thfe system capabilities to ifiH iii brdetls'kid submit admitting and other 
forms from end-user devices. The present invention provides' the capabilities for the large 
number of forms and orders relating to patient care in a inedical institution to be fiUed-in 
from fehd'-user ^devices.* Different lisers have different roles arid capabilities for filiing-in 

- fomis. For' example, i)hly physicians can enter order' for' medications or treatments. The 
rules of this module coritrol access to forms and" the ability to fill-in of modify them based on 
user attributes sirnilar to those governing' general aec^^^ 

^PRINTING RULES MODULE: ' • * • * ^ -^^^^ • * ' - 

• The hiles'of the prihting rules module detefriiines print formats* in accordance 

' v^th a' usefs printing preferences stored in the personalization database.* Therefore, upon a 
user print request, the business-server objects can print pages personalized and formatted 
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... . ,^ccording to. the user's specifications... For example, these rules cm. specify that images not be 
printed or be printed only at a reduced size. The visers.can change their own printing 
preferences. . 

ALERTS & REMINDERS (NOTIFICATION) RULES MODULE: . : 
^ The rules of the alerts & reniinders rules module (also called the nptification 

rules module) of the personalization family determines personalization, formatting, and 
presen^tion of the resulte generated by the alerts & reminders rules module of the decision 
support family. Personalization and formatting rules detennine the physical layout and 
screeri presentation of alerts and reminders. Presentation rules can also determine the manner 
10 of transmission of these rnessages, which may be a function of the priority indicated for the 
message. For example, a n^le of this module may spepify: IF the message is an urgent alert, 
THEN page me and send me e-mail with the alert appropriately formatted. Another 
exemplary rule may speciiy: IF the message is a reminder, THEN send me formatted e-mail 
only. 

15 Rules Module - Decision Support Family 

PQcision supppit functions can.be easily integrated into the structure of 
S . ^^j^ engine 68, and rules modules by simply introducing 

• ^- ^^additional^^ which^prpyid^, decision support reasoning capabilities. Such 

dQcision suppQrt seryic^^ are adyantagepus^in the context of a medical institution. :Therefore, 
20 decisio^ support rules modul^ fs^ includes at least an alerts & reminder rule 

module, a diag;np.sis,pd m^^ rule^ module, and a drug interaction rules module. 

The knowledge-base of decision support rule modules is typically obtained 
and maintoinecl ^^^^f skill in the art will. understand how other decision 

.,.r. . support seryices^th^t. a finds advantageous can be implemented in 

25 additional decision support, rules, modules to be added to this family and knpwledge base.=^ : 
ALERTS AND REMD^ERS^ R^ 

The ^iles.al!srts.& reminders rules module of the decision support family 
determines, decision support functions available to. nptify caregivers of generally-urgent or 
notable events. In more detail, decision support alerts are generated to draw the user's 
30 . attention to iffgent exents, ?.g. abnormal test results, urgent^orders;pr medications not 
, processed, possible, drug. interaciions, etc. For example,. such a rule- may be: IF white cell 
count is greater than 20,000, THEN generate an alert message. Decision support reminder 
messages are generated for more routine and less urgent events, or can be entered by the user 
for latter display as a "tickler" message. 



BNSDOCID: <WO 0057339A2J_> 



wo 00/57339 * 29 PCT/EP0D/b2753 

' These rules ai-e patient, ejjisode an They allow only certain 

classes bf patients to be examined with a certain frequency for certain types of events to 
generate certain alerts and reminders. For example, a physician may wish' to routinely scan 
only diabetic patients for abnormal glucose trend events arid only patients being administered 
5 ' cancer chemotherapeutic for dangerous white cell count events.' Rules of the "Alerts and 
Reminders" module allow a user to choose which events rank as more urgent alerts and 
which events are adequately addressed by Tess lirgerit reminders. Further, these rules can also 

* specify which alerts require urgent attention, and Which event are not urgent and are 
adequately addressed by reminders. For example; soriie physicians may want to be alerted 

10 ^ about certain Events on a particular patient whereas others may only want reminders. Alerts 

- and reniinders can optionally be assigned a priority. For example, an alert may be marked as 
"urgent". ' - . - *' ^ - - 

DIAGNOSIS & INTERPRETATibN RULES MODULE: ' ' * 

The diagnosis & interpretation rules module includes rules representing. 
1 5 diagnostic support and interpretation of parti'emar conditions arid results. ~ Thes'e rulesxan 
scan a GPR of a particular patient and provide suggested dia^oses or interpretations. 

' Such rules* are Well known- in thfe'Srt. F6r example^ the following cari be coded 
in a convenient rales Isiiiguage : IF the patient li£s fevet, sOTe throdt^^and • - ^ 

* "^examination has white' exudate in the posteridr rfegiSn oT the pharynx and enlarged lymph 
20* ' -nodes in the anterior cervical-yegionj-ahd laboratory tests revealing a positive strepYococcal 

' antigen antibody blood level, TflEN the patient has^slre^tocobcal phaiyngitis. " ' ^ 
. ^ DRUd INTERAGTION- RULES MODULE: ^ ' ^ 

- ' - = ' TTie drug Interaction niles module iriclu36s^m^^ 

di^g intei^dtions and can provide' warnings of pbteritiki^adVgrse^'ihteraction^^ a particular 
25'- - patierit given ntformiaiion oh Ae'n^^ 

Such rules are well known in the art. For examplie, the foUov^ng can be coded 
. iri 'a corivenieht mle^ language: IF a patient i^ iaking a*m6ho'afriine dxidase inhibitor, such as 
depreneyl- and antidepressants, '^iicfi *as Pfoiiac, THEN the patient can have a fatal reaction. 
' Prioritizatioh^ arid Update of Rule Modules ' ' 
30 . . 'As discussed previously- in' orde^ 

* processing, mle and rule rriodules are prioiitized ariii are processed liy the rules engine in 

' priority b'rdef: The highest priority rule modules are th^ access privileges and the orders & 
forms rule modules.- For example, the GUI rules module has a lower priority, because, if a 
user is not authorized to view certain types of information for a particular patient, then that 
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, i^ormation should not be accessible even.if the user indicates, otherwise in.the screen layout 
preferences in the GUI rules module. Similarly, if a user is not authorized to order for a 
particular patient, then that user should not be able to djsplay orders and forms menus on a 
display screen. 

5 ^ At the next level of priority modules is the platform rules module. If the 

capability of the platform can not handle certain information, e.g., high-resolution images, 
then rules .which deal with the formatting and personalization of that information, e.^., 
preferences for how to display high resolution images, need not be evaluated. 

Therefore, at the lowest priority level are the GUI layout, the alerts & 
10 reniiiiders, the help, and the printing rules modiiles. 
Push Technology for Rules Updating 

Where the rules modules of this invention are duplicated on several second- 
tier server systems or where certain of ^e rules modules h^ve been downloaded to capable 
end-user computers, it is preferable to update in a coordinated fashion all copies of the rules 
1 5 modules. It is similarly preferably to update other software components that are necessarily 
duplicated on various computers and device of this systern, Such updates are done by 
installation means. 

^ ^^F>/ii'5\r:^r^^^ perform such coordinated update, push technologies are advantageously 
employed as,installation means. Push technologies are generally taken herein to mean 

20 technologies that maintain information on where software components are or should be in a 
system, and, when presented with a new software component or an updated existing software 
component, will automatically place this component in the appropriate locations in a systern. 
For example, push technologies can copy an updated rules module to all middle-tier server 
systems and to all end-user devices to which it has been downloaded, 

25 One preferable push technology is available in the Castanet System of 

Marimba, Inc* (http://www.marimba.com). 

Push technologies have further applications for providing medical news 
chaimels and information, medical education, medical reference information, and so forth to 
end-users at end-user devices from news servers on the Internet. Where such broadcast is 

30 provided, the type and formatting of the broadcast information can be controlled by 
additional personalization mles modules in the maimers previously described. 

The systems and methods of his invention are not limited to the preferred 
domain of the activities of medical institutions. One of skill will understand how the same 
systems and methods can be applied to the activities of other institutions, such as, for 
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example, banks, insurance cbmpariies, airlines, Wels, maihufacniririg corporatioiis, and so 

^ forth: ' - ' ^ --^ - ' ' - ' ' ' 

- ' - ' ' ' In order to create a business rule application according to this invention in 

another domain, the first steps are to create rules and rule-based business server objects, 
5 'Different rule-based business-server objects can be implemented for different rule modules to 
miprove scalability and maintenance. In a medical application, different business-server 
objects can be created for handling help, for orders &'forms, for diagnosis & interpretation, 
and so forth. The rules can also be corhpiled to create Java^ classes. 

- It should now be appreciated that the objects of the present invention are 
10 satisfied. While the present invention' has been described in particular detail, it should also 
be appreciated that numerous modifications are possible-within the' intended spirit and scope 
of the invention." * ' 

All references cited herein are incorporated herein by reference in their- 
entirety and for all purposes to the same extent as if each individual publication or patent or 
15 patent application was specifically and individually indicated to' be incorporated by reference 
in its entirety for all purposes. 
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CLAIMS: . 



^ • An Object-oriented system for computerizfed patient record (CPR) prbsentation 

to a user at an end-user device, the object-oriented system for impleineniation on computers 
connected by a network, the system comprising: 

one or more medical-records-server objects comprising CPR-request methods 
that input requests for CPR data, access requested data'in CPR databases, and return 
requested CPR data, 

a preseritation application resident in the end-user device that accepts user 
requests, invokes methods of tusinesis-serverobjects Avith jiarameters representing user 
requests, and displays responses returned by the business-server object niethods, 

one or more business-server objects comprising the business-server object 
methods invoked by said presentation application, 

vvhereinithe business-servet'object methods'ij^cess input p^ 
;^^«^^«»^'GPR diata is to'b^ obtaihed, and if so which' CPR data, authorize access to the 
" '^.s^ermined CPR aata,4rivoke tKe CPR^i-equest methods of smd medical-r^dbrds-server 

objects to obtain authorized CPR data, format a response including any retumed'cPR data, 

and return the response to said presentation application, and 

-. • ; n -wherein tlie auffidnzing and fOririattihg are responsive to a plurality of rules 

' retrieverfrorn i fule database arid to' personalization data retrieved from a personalization 
database, the rules comprising (i) access-control rules for authorizing access to cipR 
information and (ii) presentation-control rules for guiding formatting of responses. 

^- • system of claim 1 fuither comprising one of more rules engines that 

^processes rules-ahd personalization date to deterinin^ riiles fecoihniendatibns'.^ci wherein 
the authorizing and formatting of the business-server object methods are responsive to rules 
recommendations retvimed from calls to said rules engines. 

3. • - 'The System of claini'2 Whereih one'of 'more rules are downloaded to the end- 

user device, and wherein display by tlie preseritation applicatibh is respoi^ive to 
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recommendations returned by calls to a rules engine resident in the end-user device upon 
processing the downloaded rules. 



4. The system of claim 1 wherein related rules are grouped for storage and 
retrieval. in the rules database into rule modules, which are separately stored and retrieved in 
the rules database. 

5. The system of claim 4 further comprising installation means for installing new 
or updated rules modules in the rules database. . . * ' 

6. The system of claim 4 wherein the rules-modules have a priority, and wherein 
retrieval of the rules modules frorn the rule database by the business-server objects or by the 
rules engines is responsive to the priprity of the rules modules. . , : f 

7. The system of claim 4 wherein the access-control jules further comprise an 
access-privileges rules module that authorizes access.to^CJPR.data.Gonceriiing a patient in 
dependence on personalization data inpluding characteristics of the^role of the user in. an 
institution, of the role of the user vnih respect to the^p^ient^ and^pf the^access^^ of. 
the user. „ • . .., . . . ^ 

8. The system of claim 4 wherein the accessrcpntrol rules further comprise an 
orders-and-forms mles module that. authorizes a userto.^ubmit.orders and forms, relating to a 
patient.^ , . -^^ - . . i'; . rrr::^^:. ^a. : V'* 

9. The system of claim 4 and wherein the presentation-control mles further 
comprise a platform rules module that recommends, rje3ponse formatting in dependenQe on 
data including the characteristics of the end-user application,, the ^nd-iiser device, and the 
network. . : . : ^ . *: , ^ 

1 0. The system of claim 4 wherein the presentation-control rules fiirther comprise 
a GUI-layout rules module that recommends response formatting in dependence on 
personalization data including graphical-user-interface layout preferences of a user. . :„ 
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.. ^}-. . , system ofclaro 4 wherein the presentatipn-control rules further comprise 

a help rules module that recommends formatting.and display ofhelp information in 
dependence on personalization data including characteristics of the experience pf a user using 
the system. 

^ 2 ■ The system of claim 4 wherein the presentation-control rules further comprise 

a printing rules module that recommends formatting of printed responses in dependence on 
personalization data including characteristics of the printing, preferences of a user. 

^ 3 • The system of claim 4 \vherein the rujips further comprise decision-support 

rules for providing decision-support recommendation to a user. 



14. The system of claim 13 ^vh^rein the. decision-support rules modules further 

comprise a first alerts-and-reminders rules module for providing alerts and reminders 
messages concerning conditions of one or nipre Patients, ^d wherein the presentation- ; 
control rules f^uther comprise .^ second alerts-and-remind?rs rules module for recommending 
the fonnatting and presentation of the alerts^m^^ . , -. , 

..-y The system of ?lam^^ 
diagnosis-and-inteipretatipn rule§^ cojiiprising rules for providing recommended . i, 

diagnoses and interpretations of a patient's condition. . - , 

;. ... ,7]^e system o/plaim 13 wherem the decision-support. rules further comprise a 
dnig-interaction rules module te pirgyides recommendations on possible dmg-drug 
interactions. 

17... The systein of claim l yherem sm^ 

•I^.X?*""^"?^^^-^ browser program whiclj requests and digslays data formatted according to the 
hypertext markup language (HTML),, ^d wherein the object-oriented system further- 
comprises a hypertext trarisfer. protpcpl (HTTP) server for providing requested HTML- 
formatted data and Java"", applets to said presentation application. 
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* • 18. * - The system of claim 1 whferein the end-iiser device comprises a computer with 
a graphical display device tod'procbssing'meaiis, and wherein the processing means 
comprises' ail ORB and said presentation application. 

5 19. The system of claim 1 wherein the end-user device comprises a personal 

digital assistant or a television set. 

20. - * The system of claim 1 further coinprising object request brokers (ORBS) 
which reside on each computer of the system and which provide for remote method 

10 ' invocations across the network 6f object methods. 

21. A method of presenting computerized patient records (CPR) on an end-user 
device by an object-oriented isystem implemented on computers connected by a network, the 
method comprising: . . . ^ 

1 5 - ' accepting a user request arid invoking one or more methods of business-server 

* objects, wherein parameters input to the business-serverlobject methods represent the user 
request, and whereih said accepting afid invoking are performed by a presentation application 
in the end-user device, - ..^^ry^,^^.?.-^^}^::. . 

• — / determining if CPR data is to be obtained for the us_er, and if so which CPR 

20 data, wherein said determininig is perfonrfed by the Busihess-server bbjects'according to the 
input parameters, ' ' 

authorizing the determined CPR data according to authorization 
' reconmiehddtiohs returned ifroin processing both 

rules datal^ase and also of personalization data retrieved fi"6m *a personalization database, 
25 wherein said authorizing is performed by the business-server objects, 

invoking one or more methods of medical-records-server objects, wherein 
• pararrieters^input to the medical-records-servef objects represent' the* authorized CPR data, 
. Wherein the medical^records-^rver objects 'return the authorized CPR data retrieved from 
CPR databases, and wherein said invoking is performed by the"" business-server objects, 
30 - " ■ formatting' and returiiing a^ response to the presentation application, wherein 

the response includes retumed CPR data, vvhereih the Tdnnatting is according to formatting 
recommendations retumed from processing of presentation-control rules retrieved from the 
rules database and personalization data retrieved from the personalization database, and 
wherein the formatting and returning is performed by the business-server objects, and 
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displaying the retimed response to the user by the presentation application. 

22. The method of claim 21 wherein rules processing further comprises calling a 
rules engine by the business-server object methods,. and wherein, the rules engine returns to 

5 the business-server object recommendations resulting from rules processing. 

23 . The method of claim 2 1 further comprising, prior to said displaying, further 
formatting of the returned response by the presentation application. 

10 24. The method of claim 2 1 wherein related rules are grouped for storage and 

retrieval in the rules database into prioritized rules modules, and wherein retrieval of rule 
modules is responsive to rule module priority. 

25. The method of claim 24 further comprising a step of processing decision- 

1 5 support rules retrieved from the rules database, wherein the decision-support rules processing 

is responsive to the parameters input to the business-server object methods, and wherein the 
recommendations returned from the decision-support rules processing are 
• ... - included in the formatted response. 

20 26. The method of claim 25 wherein the decision-support rules comprise one or 

more rules modules selected from an alerts-and-reminders rules module, or a diagnosis-and- 
interpretation rules module, or a drug-interaction rules module. 

27. The method of claim 24 wherein the access-control rules comprise one or 

25 more rules modules selected from an access-privileges rules module or an orders-and-forms 
mles module. 



28. The method of claim 24 wherein the presentation-control rules comprise one 
or more rules modules selected from a platform rules module, or a GUI layout rules module, 

30 or a help rules module, or a printing rules module. 

29. The method of claim 21 wherein at least one presentation application, at least 
one business-server object, and at least one medical-records-server object reside on different 
computers, and wherein said steps of invoking methods further comprise passing of method 



BNSCXX:iD: <WO 0057339A2_L> 



wo 00)^7339 



37 



PCT/EPOO/02753 



invocations between different computers by object request brokers resident on each 
computer. 

'•'•30. *An object-oriented corriputer program for performing th^^ 
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